home *** CD-ROM | disk | FTP | other *** search
- Path: seagoon.newcastle.edu.au!usenet
- From: mazz@faceng.newcastle.edu.au (Richard Mazzaferri)
- Newsgroups: comp.lang.c++
- Subject: Re: Fastest Sorting Algorithm?
- Date: Wed, 10 Apr 1996 09:16:03 GMT
- Organization: Newcastle University
- Message-ID: <316b7b66.13881382@news.newcastle.edu.au>
- References: <Dou55w.7MB@novice.uwaterloo.ca> <DpAxtI.3w9@undergrad.math.uwaterloo.ca> <4k4unk$15qe@sol.caps.maine.edu> <4k680p$6fs@longwood.cs.ucf.edu> <4k6hdg$5ob@blackice.winternet.com>
- NNTP-Posting-Host: tesla.newcastle.edu.au
-
- jdege@winternet.com (Jeff Dege) wrote:
-
- > On 6 Apr 1996 12:01:13 -0500, Mark Schnitzius (schnitzi@longwood.cs.ucf.edu) wrote:
- > :
- > : Is it really 2logn? My understanding was that a sort couldn't be
- > : less than nlogn... More info, please.
-
- > No sort that works on comparing elements can be less than O(n*log(n)).
-
- You should probably add modify that statement to "No sort on a serial
- architecture that works on comparing elements..." before parallel
- processing afficionados jump into the fray :-)
-
- *Any* sorting algorithm on a serial architecture must take at least O(n)
- because it has to process each input element at least once. So, the
- claimed sorting algorithm running in O(2log n) must be running on a
- parallel architecture - which is probably not of any use to the author of
- the original question.
-
- > trickSort(int A[], int size)
- > {
- > int i;
- >
- > for (i=0; i<size; i++)
- > A[0] = 0;
- > }
-
- Which of course (disregarding the fact that the algorithm fails to sort its
- inputs at all) is O(n) - much slower than the claimed O(2log n) algorithm
- :-)
-
- Have fun,
- Mazz.
- mazz@faceng.newcastle.edu.au
-